Canvas渲染会取代DOM吗？
【编者按】Canvas 与 DOM 是开发者进行浏览器渲染时最常用的技术方案，关于这两门技术的对比文章屡见不鲜，各自拥有一批忠实的开发者。然而，Google 近期的一个决策可能会改变现状。
作者 | Matthew MacDonald
译者 | 弯月
Google最近决定使用HTML的<canvas>来渲染Google Docs中的一切，引起了轩然大波。人们的担忧不无道理。曾几何时，Web的目标是分享架构化信息，包含合理的元数据，而且易于开展合作。然而，现在却成了在浏览器的沙盒中运行的半透明模型。
从HTML元素切换到Canvas上的像素渲染，Google的这个决定并非史无前例。很多先进的Web早就突破了传统Web元素的束缚。Google地图多年前就开始使用Canvas渲染了。VS Code使用canvas来绘制像素级的终端界面。Google新兴的跨平台UI框架Flutter在浏览器中也会默认使用Canvas。
但这次感觉不一样。canvas渲染加上WebAssembly等其他技术，点燃了导火索。似乎我们熟悉的那种模式（下载JavaScript代码并在HTML文档中执行）只不过是Web开发进化之路上的一个过客而已。
换一种说法，我们曾理所当然地认为，我们可以看到运行中的代码，检查标签，还可以查看CSS。但是，也许这一切只不过是软件设计长河中的一段小插曲。
那么接下来会发生什么？
人们总是对Google亦步亦趋。
大约15年前，Google是异步JavaScript调用（后来称作Ajax）的先驱。他们主导的这种技术被用到了Gmail和Google地图中，后来成了Web开发的基础。现在，Google开始在canvas上画UI，等于向新一代的Web开发者宣告了这种做法的合理性。
目前，使用canvas渲染还有着不低的门槛。在Google Docs的构建过程中，Google重新发明了许多人们习以为常的东西，例如精确定位、文本选择、拼写检查、重画调优等。今天，只有少数几家公司才会考虑采用canvas渲染来获得可能的性能提升。
最大的问题是可访问性。为了遵守可访问性的法规（作为像Google这样的政府供应商来说，合规是必须的，对于希望尽社会责任的企业来说，可访问性也非常重要），应用程序必须满足特定的要求。基于canvas的Google Docs依然需要为屏幕阅读器、屏幕放大镜、高对比度设置、低敏捷度特性等提供支持。他们的做法之一就是在真正的canvas渲染的内容之外，再专门为辅助工具实现一个不可见的DOM。当然，这两个模型之间要保持完美的同步。
目前还没有现成的标准供开发者在使用了canvas渲染的应用程序中添加可访问性支持。但是随着canvas渲染技术的流行，这种情况也会改变，而且很难说会以多快的速度改变。Google越来越多地采用该技术，会给该领域带来大量的关注、发展和进步。很快就会出现许多库，然后就会出现标准和API。我们可以给阿特伍德定律加一条：
“所有能用JavaScript实现的最终都会用JavaScript实现，哪怕需要改进JavaScript。”
语义Web已死
从整体来看，Google的行动只不过是漫长旅途中的一小步而已。从Web诞生那一天开始，野心勃勃的开发者们就在想尽一切办法冲破页面模型和HTML抽象的束缚。当年有Flash之类的插件。从那时起，对于Web的两种不同观点就开始了明争暗斗：Web究竟是结构化文档容器，还是应用程序容器？
这场冲突最激烈的部分莫过于XHTML的死亡。XHTML是一个异常严格的Web标准，旨在实施纯粹的语义化，而这个目标Web从未实现。XHTML曾被誉为“Web的未来”，但突然就被HTML5打败了。
而HTML5对于Web的定义是“浏览器制造商们一致同意的任何标准”。它包含了一组实际的JavaScript API集合（地理位置、本地存储、Web套接字、后台worker等），这些API可以像搭积木一样嵌入到页面中。当然，它也包含几个新的语义描述元素，但在嵌入信息方面，唯一的激进功能就是microdata，然而这个功能不久后就被除名了（很大程度上因为Google和苹果没兴趣实现该功能）。
Canvas渲染显然站在富语义页面的对立面。它是一个黑盒子，其内部的情况浏览器无从知晓。
Canvas渲染将一切权力都交给了应用程序。通过控制像素秒回，你可以实现任何事情：可以阻止自动化工具，绕过广告拦截器，限制浏览器功能（如搜索、文本复制等）。它只不过是用JavaScript实现的Flash或Silverlight，不需要安装，也没有兼容性问题而已。
未来属于WebAssembly和二进制块
可能你认为Canvas渲染很重要，但从Web开发的全局来看，它只不过是小巫见大巫。真正的巨兽毫无疑问是WebAssembly，这是一个所有现代浏览器都能理解的底层二进制指令格式。
如今，当你访问一个由WebAssembly制作的网页时，你运行的实际上是预先编译好的代码，这些代码只不过比汇编语言高级了一点点，比那些极限压缩并混淆过的JavaScript还要难懂。WebAssembly被用来运行游戏、解码基因序列，或者用来运行更高层的框架，如.NET的Blazor环境。WebAssembly能够在不离开浏览器沙盒的前提下提供近乎原生应用的性能，与之相比，对于不透明Web应用程序的担忧是那么苍白无力。
目前，WebAssembly需要一层复杂的JavaScript互操作层才能访问DOM。但下一个阶段是WebGPU，这是已遭废弃的WebGL项目的继任者。WebGPU和WebGL都采用了同样的方法，即为canvas渲染的表面提供优化后的访问。与浏览器实现的硬件加速结合起来，就可提供一个底层的绘图表面，供开发者构建下一代Web应用程序，或者构建下一代库和框架，为下一代Web应用程序提供动力。依照WebAssembly的炒作力度，很难想象未来的Web开发不会使用WebAssembly和WebGPU。
为什么不呢？毕竟，如果开发者要从头开始开发Google Docs，他们绝不会选择Google Docs一直沿用至今的模型（构建在HTML布局引擎上的文档布局引擎，与一个JavaScript抽象紧密耦合）。这个模型之所以存在，只不过是因为它能用而已。从设计的角度来看，它是一个扭曲的奇迹，而不是优美的软件。
即使是未来的Web应用程序，传统Web的观点也依然会存在于适合的地方，比如那些以内容为主的网站（科技文章网站、亚马逊产品目录等）。这些网站没有理由重新发明轮子、自定义渲染过程，并重新解决可用性的难题。但在未来，这些网站的行为不再是Web内容的标准。
相反，应用程序模型会完全打破今天的HTML/CSS抽象的桎梏。这种变化会让开发者回到一个完全自由但支离破碎的世界，他们需要从大量的语言和UI模型中做出选择。如果说过去的历史有何意义，那就是世界比我们想象得更近。
原文链接：https://blog.container-solutions.com/10-predictions-for-the-future-of-computing
声明：本文由CSDN翻译，转载请注明来源。